home *** CD-ROM | disk | FTP | other *** search
/ FishMarket 1.0 / FishMarket v1.0.iso / fishies / 126-150 / disk_133 / overscan / overscan.doc < prev    next >
Text File  |  1992-05-06  |  6KB  |  129 lines
  1. (overscan.doc)
  2.  
  3.    Overscan
  4.   ----------
  5.  
  6.   By Ari Freund - 20/11/87
  7.  
  8.  
  9.  General
  10.  
  11. Patches up the Intuition library so that sizable windows with MaxHeight = 200
  12. (or 400 in lace), and screens with Height = 200 (or 400 in lace) will take
  13. advantage of the PAL overscan capability of Intuition V1.2.
  14.  
  15. To install the patch type: overscan
  16. To remove it type:         overscan delete
  17.  
  18. Compile and assemble using Aztec C V3.40a: cc overscan.c +C +D
  19.                                            as overscan_lib.asm
  20. Create a library file using the librarian: lb overscan.lib overscan_lib.o
  21. Link using Aztec C V3.40a:                 ln +S overscan.o overscan.lib c.lib
  22.  
  23. You may also execute the overscan.make file.
  24.  
  25.  
  26.  Detail
  27.  
  28. 'overscan' patches the Intuition jump vectors to OpenScreen() and OpenWindow()
  29. and points them to its own functions: screenpatch() and windowpatch().
  30. These functions check if apropriate, and if so, change the Height/MaxHeight
  31. member in the NewScreen/NewWindow structure to STDSCREENHEIGHT and send
  32. the structure to Intuition to do the openning. 'Apropriate' in this context
  33. means that the screen/window is not a super/custom bitmap, that its intended
  34. Height/MaxHeight is 200 (or 400 for lace), etc. Note that with screens the
  35. patch actually causes a larger screen to open, whereas with windows it only
  36. allows the resizing of it to the full height of the screen but the initial
  37. window opens at its intended size.
  38.  
  39. Before changing Intuition's vectors, overscan saves the original vectors
  40. at data.oldscreen and data.oldwindow. After doing its thing, each function
  41. (screenpatch() and windowpatch()) calls its respective vector to get Intuition
  42. to do the openning job. screenpatch() also uses IntuitionBase.
  43.  
  44. In order for the patch functions to stay around after overscan finishes
  45. and exits (and gets unloaded), the segment containing the functions
  46. and the relevant data (IntuitionBase, oldscreen, oldwindow, etc.) is
  47. disconnected from overscan's SegList, so that when it (overscan) exits,
  48. they are not unloaded. A BPTR (data.myseg) to the segment is also left behind.
  49.  
  50. Since overscan has the capability to delete the patch and restore
  51. Intuition to normal, it must be able to find the segment left behind
  52. from the invokation of overscan which installed the patch. Thus, when
  53. installing the patch, overscan adds a public message port (data.port)
  54. to the system's message port list. In addition, the name of this port is
  55. also left behind.
  56.  
  57. In order to avoid unloading the patch by one task while another is using it
  58. to open a screen/window, each time either routine is entered it increments
  59. the in_use count variable by one. When the routine exits it decrements the
  60. count. When 'overscan' is called to delete the patch it first checks to see
  61. if the patch is in use (in_use!=0), and only if not does it delete the patch.
  62. This greatly reduces the danger of deleting the patch while it is in use.
  63. However, it does not eliminate this possibility entirely. If the patch is
  64. unloaded after the 68000 has executed the 'jmp' instruction in Intuition's
  65. vector table (called by a task attempting to open a screen/window) but before
  66. it had a chance to execute the first instruction in the patch (increment
  67. the in_use count) the system may crash. A similiar thing may occur between the
  68. 'decrement the in_use count' and the 'rts' instructions at the end of both
  69. routines.
  70.  
  71. Thus when 'overscan' has finished installing the patch
  72. and has been unloaded, the following items remain:
  73.  
  74.    struct myvars {
  75.       struct MsgPort port;              /* the message port */
  76.       BPTR myseg;                       /* BPTR to one of the segments */
  77.       ULONG oldscreen;                  /* the original Intuition vectors */
  78.       ULONG oldwindow;
  79.       ULONG in_use;                     /* count of tasks using the patch */
  80.    } data;
  81.    struct IntuitionBase *IntuitionBase; /* pointer to Intuition */
  82.    char myname[]="<the port's name>"    /* the message port's name */
  83.  
  84.    void screenpatch()
  85.    {
  86.      ... mainpulate the NewScreen struct ...
  87.      ... call Intuition via data.oldscreen ...
  88.    }
  89.  
  90.    void windowpatch()
  91.    {
  92.      ... mainpulate the NewWindow struct  ...
  93.      ... call Intuition via data.oldwindow ...
  94.    }
  95.  
  96. Note that the both the data and the code for the routines reside in one (CODE)
  97. segment. This is done for the sake of compactness.
  98.  
  99. In order to avoid clashes between tasks using the patch simultaneously
  100. I have written the patch in assembly language. The patch only alters
  101. scratch registers (a0/a1/d0/d1) and saves intermediate values on the
  102. stack.
  103.  
  104. Before returning to the caller, after possibly altering the Height/MaxHeight
  105. member, each routine restores the Height/MaxHeight member to its original value.
  106. This way the calling program gets back exactly the same NewScreen/NewWindow
  107. structure it sent to Intuition.
  108.  
  109. When 'overscan' is invoked to remove the patch, it FindPort()'s data.port.
  110. At fixed offsets from data.port it finds the addresses of Intuition's
  111. routines (data.oldscreen and data.oldwindow) and puts them back
  112. in Intuition's vector table. It RemPort()'s the data.port and using myseg,
  113. which too is at a fixed offset from data.port, chains the segment to the
  114. end of its (overscan's) SegList. 'overscan' then simply exits and lets DOS
  115. unload itself (overscan) together with the patch. You can now appreciate why
  116. myseg, port, oldscreen, and newscreen were placed together in a single structure
  117. (data). This was done to ensure that these variables will be compiled at this
  118. precise order relative to the message port.
  119.  
  120. In order to isolate the patch from the installing/deleting function
  121. (main()), it is necessary to assemble it seperately and then link
  122. it as a library to main() using the +S option, which will cause the patch to
  123. reside in a different segment than main()'s. Compilation of overscan.c
  124. with the +C and +D options is necessary so that code and data references
  125. be compiled as absolute mode references, which is essential for correct
  126. operation of the patch routines.
  127.                       ________________________________
  128.  
  129.